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BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The present invention relates to a first-in 
first-out buffer (FIFO) used as an interface between 
simulation models, and in particular to a dynamic FIFO that 
facilitates fast simulation and an appropriately-sized 
implementation in hardware and/or software. 

Description of the Related Art 

[0002] Performing one or more simulations allows a user 
to determine whether a design functions correctly in a 
software environment before implementing the design in a 
combination of software and silicon. To perform a 
simulation, a user can divide the design into ''blocks", 
called models herein that model the behavior of individual 
components or sub-systems. 

[0003] Generally, running models during simulation at a 
higher level of abstraction is faster than running models 
at a lower level of abstraction. These levels of 
abstraction are called execution domains herein. For 
example, a system level execution domain can provide a 
high-level description of a block. In contrast, a register 
transfer level (RTL) execution domain can provide an 
intermediate -level description of the block. A gate level 
execution domain can provide a very detailed description of 
the block. 
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[0004] As designs increase in size and complexity, 
simulations of these designs become slower. To address 
this problem, a user may use models of different execution 
domains to describe the blocks of the design. For example, 
for the design of a cell phone in a wireless communication 
system, the hardware of the cell phone may be simulated at 
the RTL or gate level. Of importance, simulating the cell 
phone's ability to transmit and receive messages from a 
station may require simulating some portions of the 
station, but not at the same level required for the cell 
phone itself. Thus, the station that facilitates 
communication with the cell phone may only need to be 
simulated at the system level. Because the station is 
described at the system level, rather than the RTL or gate 
level, the simulation time to test the cell phone design 
can be significantly reduced. 

[0005] Of importance, different execution domains can 
have different timing variables. For example, both the RTL 
as well as the gate level execution domains are timed. 
That is, the RTL and gate level execution domains include 
delays, e.g. instructions to wait for a given amount of. 
time or the occurrence of an event- However, a system 
level execution domain may be timed or un- timed. 
[0006] Un- timed models, which include algorithmic or 
data flow and control graphs, are frequently used for 
blocks of the design that have mathematical properties, but 
no timing considerations. For example, design blocks such 
as integer accumulators or adders could be simulated using 
un-timed models. An integer accumulator functions by 
adding to its accumulating output, which is initialized to 
zero. Specifically, as long as its input is "1", the 
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output of the accumulator would generate "0, 1, 2, 3" and 
so forth. An adder functions by adding its inputs to 
generate an output. Thus, if a two-input adder received 
the output of the accumulator as its two inputs, the adder 
would generate ''0, 2, 4, 6" and so forth. 

[0007] The values of interest in a model, which could be 
inputs and/or outputs, are called ''tokens" . In a 
simulation, tokens are ''generated" and "consumed" by the 
models. To ensure that tokens; are not "lost" when they are 
generated and then transferred between models, these tokens 
must be saved in memory for consumption by a destination 
model. This memory not only saves the generated tokens, 
but must also maintain their order of receipt. In many 
simulators, a first-in first-out buffer (FIFO) can be used 
to save the sequence of generated tokens. A FIFO creates a 
queue wherein the oldest token received is the next output 
token. The size of- the FIFO needed between two models 
instances depends on the number of generated tokens and the 
number of consumed tokens per model activation. Note that 
the number of tokens produced and/or consumed can vary from 
activation to activation. 

[0008] In a prior art simulation, a user must manually 
determine the appropriate size of the FIFO. In simple 
designs, such as the exemplary design described above (i.e. 
the integer accumulator and adder) , the user can easily 
determine the appropriate size. Unfortunately, standard 
integrated circuit designs are much more complicated than 
this exemplary design and manual re-sizing becomes very 
expensive if not logistically impossible. 
[0009] Specifically, for the simulation to run 
accurately, i.e. without deadlock and at optimal speed, the 
user must properly size the FIFO used as an interface 
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between the models. To determine the proper sizing, the 
user must consider the number of tokens generated by the 
source model as well as the number of tokens that can be 
consumed by the destination model. 

[0010] Figure lA illustrates two models 101 and 102 that 
represent independently scheduled threads of execution in a 
simulation system. Each of models 101 and 102 may be 
timed, un-timed, or clocked (i.e. behavior initiated or 
resumed based on a clock signal) . During a simulation, 
models 101 and 102 can exchange data using ports, 
interfaces, or function calls. 

[0011] Of importance, models 101 and 102 are, either 
directly or indirectly, connected through fixed-size FIFOs. 
To avoid loss of data, models 101 and 102 access the FIFOs 
in a "blocking" way. Specifically, an attempt to read from 
an empty FIFO will block until there is data available in 
the FIFO. Likewise, an attempt to write into a full FIFO 
will block until there is space available in the FIFO. 
[0012] In the embodiment shown in Figure lA, model 101 
writes to a FIFO 103, which is then read by model 102 
(indicated by the arrow pointing from model 101 to model 
102) . In Figure lA, FIFO 104 can facilitate model 102 
writing and model 101 reading, or vice versa. 
Unfortunately, as now described, using fixed size FIFOs can 
result in an undesirable state called deadlock. 
[0013] For example, assume that model 101 writes to and 
model 102 reads FIFO 104. Further assume that no tokens 
are stored in FIFO 104 and FIFO 103 is full. Under these 
conditions, model 102 is blocked if it attempts to read 
from FIFO 104. Moreover, model 101 is blocked if it 
attempts to write to FIFO 103. In another example, assume 
that model 102 writes to and model 101 reads FIFO 104. 
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Further assume that both FIFOs 103 and 104 are full. Under 
these conditions, model 101 is blocked if it attempts to 
write to FIFO 103. Similarly, model 102 is blocked trying 
to write to FIFO 104. Thus, a system including fixed size 
FIFOs can be easily deadlocked. 

[0014] To solve this problem, the user can manually re- 
size the FIFO to make it sufficiently large to ensure that 
deadlock does not occur. For example, in the system of 
Figure lA including models 101 and 102, FIFOs 103 and 104 
could be re -si zed to be large enough so that deadlock is 
avoided- This manual re-sizing can be done after 
simulation (e.g. after a simulation failure, a deadlocked 
state, or a time-out condition) or before simulation. 

[0015] Re-sizing FIFOs after simulation implies that 
time has already been lost with at least one additional 
simulation and the necessary analysis- Manual resizing 
before the simulation requires a through knowledge of the 
entire design, which is very tedious and time consuming 
even in relatively simple designs. Typical designs used in 
simulation include hundreds of models with hundreds or even 
thousands of connections. In this case, manual re-sizing 
of each FIFO can become logistically impossible - 

[0016] Moreover, the already difficult task of re-sizing 
FIFOs can be further complicated by design parameters 
associated with the FIFOs as well as the source/destination 
models. For example. Figure IB illustrates pseudo code 110 
for FIFO 103. Referring to pseudo code 110, in a read 
function, code 111 waits until a token is available in 
storage. When the token becomes available, code 112 
delivers the token to the reader and code 113 and 114 
adjust the variables that count the number of available 
tokens (which is decremented by 1) and free spaces (which 
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is incremented by 1) . In a write function, code 115 waits 
until a space is available to write a new token. When the 
space becomes available, code 116 writes the token and code 
117 and 118 adjust the variables that count the number of 
available tokens (which is incremented by 1) and free 
spaces (which is decremented by 1) . 

[0017] Assume that FIFO 103 has a size of 1 (i.e. FIFO 
103 can hold a single token) , model 101 is un-timed, and 
model 102 is a timed model that must wait 500 time units to 
read a token (which would be provided in pseudo code for 
model 102, not shown) . Using these design parameters, 
model 101 can write a first token to FIFO 103, but is 
blocked attempting to write a second token because FIFO 103 
is full. After 500 time units, model 102 can read the 
first token, but is blocked to read another token because 
FIFO 103 is empty. A simulation scheduler can activate 
model 101, which in turn can write another token before it 
becomes blocked again. Similarly, the simulation scheduler 
can activate model 102, which can read another token before 
it becomes blocked again. Thus, a simulation scheduler 
will have to perform an average of two block activations to 
process and move a single token from model 101 to model 
102. The overhead associated with this pattern of blocking 
and activation can significantly increase execution time, 
which is highly undesirable. Increasing the size of FIFO 
103 to hold, for example, 1000 tokens would reduce the 
number of scheduler invocations and process activations by 
three orders of magnitude, thereby significantly improving 
simulation speed. 

[0018] Thus, as demonstrated above, estimating an 
appropriate size for FIFO 103 can be made quite complex 
even by introducing only two simple design parameters for 
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FIFO 103 and model 102. In a standard design, such design 
parameters can include complex expressions or may even be 
computed at runtime based on values of the tokens received. 
Therefore, it may not be practical or even possible to 
compute optimum FIFO size before simulation. 

[0019] Therefore, to solve this problem, some users 
resort to over-sizing all FIFOs before simulation. 
Unfortunately, this over- si zing introduces a heavy penalty 
when the design is implemented. That is, implementing 
large FIFOs in either silicon or software consumes 
expensive resources and significantly slows design speed. 
For example, over- si zing FIFOs adversely affects subsequent 
simulation operations. Specifically, the memory 
requirements of these over- si zed FIFOs may exhaust 
workstation resources, thereby deteriorating simulation 
speed due to cache effects. Moreover, large FIFOs 
implemented in hardware do waste silicon resources. 

[0020] Therefore, a need arises for a FIFO having an 
optimal size to reduce simulation time and silicon 
resources, but large enough to minimize the possibility of 
deadlock. 

SUMMARY OF THE INVENTION 

[0021] Users typically perform a simulation to determine 
whether a design functions correctly in a software 
environment before implementing the design in silicon. To 
perform a simulation, the design can be divided into 
''blocks" described by models. To ensure that data, also 
called tokens, transferred from a source model to a 
destination model are not lost, a memory device can be 
placed between these models. For accurate simulation 
results, this memory device should store the tokens in the 
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order of receipt. A standard memory device that can 
perform this function is a first-in first-out buffer 
(FIFO) • 

[0022] The size of the FIFO can be based on the number 
of tokens generated by the source model and the number of 
tokens consumed by the destination model. Manual sizing of 
the FIFO can be tedious and/or computationally difficult, 
thereby undesirably increasing simulation time and the 
possibility of error. 

[0023] In accordance with one feature of the invention, 
a dynamic FIFO can be used to minimize the possibility of 
deadlock, increase simulation speed, and decrease 
verification time. Deadlock can occur when the FIFO is 
full and the destination model is not requesting a token- 
In this state, simulation of the source model must be 
suspended> Otherwise, tokens from the' source model may be 
lost . . 

10024] • The dynamic FIFO can receive the tokens generated 
by a first model, store the tokens, and provide the tokens 
in an order output by the first model when requested by a 
second model. In accordance with one feature of the 
invention, a wait period of the dynamic FIFO can be set, 
wherein the wait period is defined by a predetermined 
number of time; units of a timed simulation kernel. The 
wait period can be decreased each time the dynamic FIFO is 
full and the second model does not request a token. If the 
wait period is reduced to zero, then the size of the • 
dynamic FIFO can be automatically increased by an 
increment. Advantageously, by using a relatively small 
initial size and incremental size increases, the memory 
resources of the dynamic FIFO can be tightly controlled. 
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[0025] In one embodiment, the dynamic FIFO can include a 
counter, wherein a counter value can be increased each time 
the size of the dynamic FIFO increases. If the counter 
value exceeds a limit, then the predetermined number of 
time units defining the wait period can be automatically 
increased. Increasing the size of the dynamic FIFO and the 
predetermined number of cycles defining the wait period can 
be performed alternately or using another schedule. 
[0026] This embodiment can be particularly useful when 
the execution speed of the dynamic FIFO varies considerably 
from that of the destination model. Specifically, this 
dynamic FIFO can automatically allocate memory as well as 
adapt its timing behavior to the execution speed of the 
destination model- In this manner, the dynamic FIFO can 
efficiently balance size with simulation speed. 
[0027] Advantageously, after simulation using either 
embodiment, the size of the optimized dynamic FIFO can be 
used as the desired size of the FIFO implemented in 
silicon. Therefore, the dynamic FIFO also efficiently uses 
silicon resources. 

[0028] In accordance with one feature of the invention, 
a dynamic memory used for simulation can include means for 
receiving tokens from a first model, means for storing the 
tokens for consumption by the second model, and means for 
providing the tokens in an order output by the first. model 
when requested by the second model . The dynamic memory can 
further include means for setting a wait period, wherein 
the wait period is defined by a predetermined number of 
time units of a timed simulation kernel. 
[0029] Each time the dynamic memory is full and the 
second model does not request a token, the dynamic memory 
device can decrease the wait period. If the wait period is 
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reduced to zero, then the size of the means for storing the 
tokens can be increased by an increment- In one 
embodiment, the dynamic memory can alternately increase its 
size and the predetermined number of time units defining 
the wait period. 

[0030] In one embodiment, after one or more simulations 
using a dynamic FIFO, subsequent simulations of the design 
can use a standard (i.e. fixed size) FIFO. Of importance, 
the size of the standard FIFO can be determined by the 
optimized size of the dynamic FIFO. Because a simulation 
using a fixed size FIFO can be performed more quickly than 
a simulation using the dynamic FIFO, replacing the dynamic 
FIFO with the standard FIFO can advantageously further 
reduce simulation time. At the end of simulation, the 
dynamic FIFO will report all the data collected during 
simulation, such as the maximum size and maximum wait 
period. These numbers may be used to design a fixed size 
FIFO that can be used for implementation. 

BRIEF DESCRIPTION OF THE FIGURES 

[0031] Figure lA illustrates a simplified representation 
of prior art FIFOs that can be used as interfaces between 
two models. 

[0032] Figure IB illustrates pseudo code that describes 
the operation of one FIFO shown in Figure lA. Note that 
Figure IB depicts only one possible implementation of a 
fixed-size FIFO, Of importance, choosing a different 
implementation will not eliminate the problems related to 
using fixed-sized FIFOs. 

[0033] Figure 2A illustrates a simplified representation 
of a dynamic FIFO that can be used as an interface between 
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models, wherein the dynamic FIFO and the destination model 
have substantially similar timing behaviors. 
[0034] Figure 2B illustrates exemplary pseudo code that 
describes the operation of the dynamic FIFO shown in Figure 
2A. 

[0035] Figure 3A illustrates a simplified representation 
of a dynamic FIFO that can be used as an interface between 
models, wherein the dynamic FIFO and the destination model 
have different timing behaviors. 

[0036] Figure 3B illustrates possible settings for the 
buffer size and the waiting period of the dynamic FIFO of 
Figure 3A. 

[0037] Figure 3C illustrates exemplary pseudo code that 
describes the operation of the dynamic FIFO shown in Figure 
3A. 

[0038] Figure 4 illustrates implementation of a FIFO in 
silicon based on simulations using the dynamic FIFO or a 
combination of the dynamic FIFO and a fixed size FIFO. 

DETAILED DESCRIPTION OF THE FIGURES 

[0039] Simulations can be performed to determine whether 
a design functions correctly in a software environment 
before implementing the design in silicon. To perform a 
simulation, a design can be divided into ''blocks" described 
by models. A first-in first-out buffer (FIFO) can be used 
to ensure that data, i.e. tokens, transferred from one 
model to another model, are not lost. 

[0040] A FIFO can be sized based on the number of tokens 
generated by a source model and the number of tokens 
consumed by a destination model. Accurate sizing of a FIFO 
can be computationally intensive, thereby undesirably 
increasing simulation time and the possibility of error. 
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[0041] To solve this problem, users can conservatively 
estimate the size of the FIFO. However, in this case, a 
FIFO is typically over-sized to minimize the possibility 
that deadlock occurs, e.g. the FIFO is full and the 
destination model is not requesting a token, thereby 
preventing continued simulation of the source model. An 
over-sized FIFO can result in longer simulation time and, 
when implemented in silicon or software, waste valuable 
resources. 

[0042] In accordance with one feature of the invention, 
a dynamic FIFO can be used during simulation to minimize 
the possibility of blockage. In one embodiment, the 
initial size of the dynamic FIFO can be set to a relatively 
small value. If blockage does occur, then the size of the 
FIFO can be automatically increased in size. In one 
embodiment, the size can be increased by increments. In 
this manner, the memory resources of the FIFO can be 
tightly controlled. Advantageously; after simulation, the 
size of the optimized dynamic FIFO can be used as the 
desired size of the FIFO implemented in silicon. 
[0043] Figure 2A illustrates a simplified representation 
of a dynamic FIFO 200 that can be used as an interface 
between an un-timed model 201 and a timed model 202. In 
this representation, dynamic FIFO 200 receives tokens 
generated by un-timed model 201 (i.e. data in) and provides 
tokens to be consumed by timed model 202 (i.e. data out) . 
Of importance, dynamic FIFO 200 has a timed behavior 203 
that is compatible with that of timed model 202. Note that 
timed behavior 2 03 could refer to an identical clock 
signal, wait statements with similar time constants, or 
other substantially similar timed behavior. 
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[0044] Figure 2B illustrates exemplary pseudo code 209 
that describes the operation of dynamic FIFO 200 during a 
read function and a write function. Note that in other 
embodiments, the read and write functions can be collapsed 
into one function or separated into several auxiliary 
functions. 

[0045] . Dynamic FIFO 200 can include a plurality of 
adjustable parameters. For example, in one embodiment, a 
user could adjust the following parameters initially set to 
default values. 

[0046] SIZEMAX: a maximum allowable size for the dynamic 
FIFO (default value of 1024*1024) . By using this 
parameter, if a real deadlock exists in the design, the 
simulation will be suspended. 

[0047] SIZE: an original size of the dynamic FIFO 
(default value of 16) . The value of the SIZE parameter at 
the end of simulation provides a good approximation of the 
value that must be used in implementation. 
[0048] SIZEINCREMENT: a value that will be used to 
adjust the size of the dynamic FIFO if an increase of the 
storage is needed (default value of 2) . 
[0049] WAITUNIT: a time resolution required for the 
dynamic FIFO (default value of 1 nanosecond). In some 
cases, the WAITUNIT parameter can be correlated with the 
time granularity of the simulation kernel. 

[0050] WAITPERIOD: an integer number of time units that 
the dynamic FIFO will wait before increasing its size 
(default value of 16) . 

[0051] In one embodiment, dynamic FIFO 200 can use the 
following internal variables for the storage of tokens. 
[0052] BUF: a data structure used for storage. This 
data structure can use various implementations, e.g. 
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size is given by the parameter size. 

[0053] NUM__FREE: a counter of available free spaces in 
data structure BUF. As the FIFO is empty in the beginning, 
NUM^FREE will initially equal the SIZE of the FIFO. 
[0054] NUM^READABLE : a counter of cells in data 
structure BUF that contains tokens available for reading 
(default value of 0). The following relation is true: 
NUM_FREE + NUM_READABLE = SIZE. 

^ [0055] Referring to pseudo code 209, in a read function, 
code 210 simply waits until a token is available in 
storage. When the token becomes available, code 211 
delivers the token to the reader, code 212 adjusts the 
variable that counts the number of available tokens (which 
is decremented by 1) , and code 213 adjusts the variable 
that counts the free spaces (which is incremented by 1). 
Note that if the condition in code 210 is not satisfied for 
a period that exceeds a given timeout, then the simulated 
system may not behave as desired. That is, in this case it 
is likely that the design contains a real deadlock in which 
the destination model waits for a token that will never be 
produced. 

[0056] In a write function, code 214 checks if there is 
any space available to store the new token. . If no space is 
available, then code 215 initializes a counter for a 
constant wait period, and code 216 and 217 execute the 
waiting till either the period is finished or space has 
been made available by a read call.. Code 218 determines if 
the wait period has been exhausted without creating new 
space. If so, code 219 will increment the size of the 
buffer storage. If this size exceeds a parameter set by 
the user, then code 220 exits the simulation. This is, in 
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this case, it is likely that a real deadlock exists in 
which the source model creates tokens that will never be 
consumed by the destination model. Otherwise, code 221 re- 
sizes the buffer, thereby creating new available space in 
which code 222 can insert the new token. Finally, code 223 
and 224 adjust the internal variables that count the number 
of available tokens and free spaces. 

[0057] Thus, dyna:mic FIFO 200 can automatically increase 
memory allocation. In this manner, the possibility of 

causing a deadlock when running the simulation of models 

I 

201 and 202 is eliminated. Note that because memory is one 
of the most expensive resources during simulation, the 
initial buffer size as well as increments could be set 
relatively small, thereby reducing the possibility of over- 
sizing the buffer. 

[0058] Moreover, setting a small initial buffer size and 
small increment size can optimize the size of the physical 
FIFO when implementing the design in silicon ^ 
Specifically, in accordance with one feature of the 
invention, the final simulated buffer size can 
substantially correspond to the size of the physical buffer 
that should be implemented in silicon or software (assuming 
that the test vectors used in the simulation are 
comprehensive and accurate) . Therefore, limiting the 
buffer size of the dynamic FIFO in simulation can also 
optimize the physical size of the FIFO to be implemented in 
silicon. In one embodiment, the maximum size of the 
dynamic FIFO can be limited by some value set either by the 
user or the simulator. 

[0059] Pseudo code 209 can quickly optimize the size of 
the buffer in the dynamic FIFO, particularly if the dynamic 
FIFO and destination model have substantially similar 
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timing behavior. In some designs where the dynamic FIFO 
and the destination model have dramatically different 
timing behavior, the dynamic FIFO can advantageously adjust 
its buffer size as well as its wait period to reach an 
acceptable balance between buffer size and delay. 
[0060] For example, Figure 3A illustrates a simplified 
representation of a dynamic FIFO 300 that can be used as an 
interface between a model 301 and a timed model 302. In 
this representation, dynamic FIFO 300 receives tokens 
generated by model 301 (i.e. data in) and provides tokens 
to be consumed by timed model 302 (i.e. data out) . Of 
importance, dynamic FIFO 3 00 has a first timing behavior 
(e.g. wait period) 3 03 whereas timed model 3 02 has a second 
timing behavior (e.g. wait period) 304. Note that model 
301 could be a timed model or an un-timed model. 
[0061] If wait period 303 of FIFO 300 is much smaller 
than wait period 304 of model 302, then dual adjustments 
may be desirable to optimize dynamic FIFO 300. For 
example, if only buffer size adjustments could be made to 
dynamic FIFO 300, the period used to make an adjustment of 
the buffer is one nanosecond, and model 302 executes only 
every one million nanoseconds, then dynamic FIFO 300 could 
quickly reach a commercially unviable size. Therefore, in 
accordance with one embodiment of the invention, the wait 
period of the dynamic FIFO can be adjusted in addition to 
its buffer size. 

[0062] Figure 3B illustrates various possible settings 
for buffer size and waiting period.. The goal of this dual 
adjustment is to balance the buffer size as well as the 
wait period. In other words, having an intermediate buffer 
size and an intermediate wait period may be commercially 
more acceptable than an extremely large buffer size and a 
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short wait period (or an extremely long wait period and a 
very small buffer size) . In one embodiment, the buffer 
size and the wait period can be alternately adjusted. 
[0063] Figure 3C illustrates pseudo code 310 that 
describes the write operation of dynamic FIFO 300, In 
addition to the parameters described for dynamic FIFO 200 
(Figure 2), FIFO 300 uses the following parameters: 
[0064] WAITPERIOD: the period that dynamic FIFO 300 will 
wait before proceeding to an adjustment of its storage 
size. Unlilce dynamic FIFO 200, in dynamic FIFO 300 this 
period may change during simulation (default value of 16) . 
[0065] WAITINCREMENT: the increment value that will be 
used to augment the WAITPERIOD, if necessary (default value 
of 2) . 

[0066] WAITMAX: the maximum allowable period. If this 
value is reached, then a real deadlock exists (default 
value of 1024) . 

[0067] Dynamic FIFO 300 also uses an internal variable 
INCR_SIZE that will determine if it should adjust its size 
or its wait period. 

[0068] In one embodiment, the read function of dynamic 
FIFO 300 is identical to that described for dynamic FIFO 
200 (see Figure 2B, code 210-213) . Figure 3C illustrates 
exemplary pseudo code 309 that describes the operation of 
dynamic FIFO 300 during a write function. In the write 
function, code 310 checlcs if any space is available to 
store a new token. If not, then code 311, 312, and 313 can 
use a counter to wait before attempting to adjust the 
parameters of dynamic FIFO 300. Code 314 determines 
whether the wait period has been exhausted. Code 315 
checks if dynamic FIFO 300 should adjust the size of its 
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buffer or its WAITPERIOD. Code 316, 317, and 318 adjust 
the size of the buffer. 

[0069] Of importance, code 319, 320, and 321 can perform 
an adjustment of the wait period. In this embodiment, code 
322 ensures that adjustments of size and wait periods occur 
alternatively. Code 323, 324, and 325 write the new value 
and adjust the internal variables that count the number of 
available tokens and free spaces . 

[0070] In accordance with one feature of the invention 
and referring to Figure 4, after running at least one 
simulation with a dynamic FIFO (step 401) , the user can 
replace the dynamic FIFO with a fixed size FIFO (step 402) . 
Of importance, the previous simulation (s) with the dynamic. 
FIFO can determine that fixed size. In this manner, 
subsequent simulations with the fixed size FIFO can quickly 
run with no or minimal blockages. After the completion of 
simulation (step 403) , the fixed size FIFO can be 
implemented in silicon or software (step 404) . Note that 
dashed arrow 405 indicates that in other embodiments, 
simulation (s) can be performed using only the dynamic FIFO. 
[0071] Advantageously, the dynamic FIFO can provide an 
interface between models specified in different execution 
domains, e.g. SLD, RTL, or gate level. Exemplary tools for 
simulating in these domains include, but are not limited 
to, for example, the System Studio tool from Synopsys, Inc. 
at the SLD level, the VCS™ and VCS MX tools from Synopsys, 
Inc. at the RTL and gate level, and the Star-SimXT™ and 
Star-HSPICE™ tools from Synopsys, Inc. at the cell and 
transistor level. 

[0072] Moreover, the dynamic FIFO can provide an 
interface between models described using different 
specification languages. For example, one model could be 
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specified using data flow graph (DFG) or finite state 
machine (FSM) at the SLD level, another model could be 
specified using System-C, C++, C, System Verilog, Verilog, 
or VHDL at the RTL, behavioral, or transaction level, and 
yet another model could be specified using Verilog, VHDL, 
or as a netlist at the gate level. In one embodiment, the 
dynamic FIFO can be specified using any standard 
specification language, such as C++, Verilog, VHDL, 
SystemVerilog, SystemC, C etc. 

[0073] Although illustrative embodiments of the 
invention have been described. in detail herein with 
reference to the figures, it is to be understood that the 
invention is not limited to those precise embodiments. 
They are not intended to be exhaustive or to limit the 
invention to the precise forms disclosed. As such, many 
modifications and variations will be apparent. 
[0074] For example, although system level, RTL, and gate 
level execution domains are described herein, the dynamic 
FIFO can be used to interface between models of other 
execution domains. These execution domains could include, 
but are not limited to, un- timed functional, transactional, 
behavioral, etc. Thus, the dynamic FIFO allows users to 
smoothly integrate various simulation engines and provides 
an integrated verification platform. 

[0075] Accordingly, it is intended that the scope of the 
invention be defined by the following Claims and their 
equivalents. 
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